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"A transaction processing method and system" 



5 The invention relates to electronic transaction processing. 

At present, an electronic transaction process for the purchase of goods or services 
includes : 

the customer making contact with the merchant to initiate the transaction, 
the merchant issuing an invoice, 

the customer sending a payment instruction to the merchant with payment 
card details, 

the merchant making an authorisation request via an acquiring institution, 

the merchant confirming the transaction to the customer if the authorisation is 
positive, and 

the merchant shipping the goods or providing the service. 

It is an object of the invention to provide an improved method and system for the use 
20 of payment cards. 

Statements of Invention 

According to the invention, there is provided a transaction processing method 
25 comprising the steps of a customer system transmitting a purchase request and 
payment instructions to a merchant system, and the merchant system processing the 
request with an acquirer system and the customer system, characterised in that he 
method comprises the further steps of: 
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a customer issuing system being notified of the proposed transaction, and 

the issuing system transmitting an authorisation to allow the proposed 
5 transaction only if conditions are met. 

In one embodiment, the customer notifies the issuing system. 

In one embodiment, the acquirer system transmits an authorisation request to the 
10 issuing system, and relays an authorisation response from the issuing system to the 
merchant system. 

In another embodiment, at least some of the authorisation conditions are 
dynamically transmitted to the issuing system by the customer when notifying the 
1 5 issuing system. 

In a further embodiment, an authorisation condition is a transaction value limit. 

In one embodiment, an authorisation condition is an indication of a particular 
20 merchant or group of merchants. 

In another embodiment, an authorisation condition is a time limit for the proposed 
transaction to take place. 

25 According to another aspect, the invention provides an issuing system comprising 
means for performing issuing system steps in a method as described above. 
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According to another aspect, the invention provides a merchant system comprising 
means for performing merchant system steps in a method as described above. 



In another aspect, the invention provides a customer system comprising means for 
performing customer system steps in a method as described above. 

Detailed Description of the Invention 

The invention will be more clearly understood from the following description of 
some embodiments thereof, given by way of example only with reference to the 
accompanying drawings in which: 

Fig. 1 is a signal diagram illustrating communication between systems for a 
transaction; and 

Fig. 2 is a signal diagram illustrating the communications at the issuer 
institution 

Referring to Fig. 1, a transaction using the method of the invention is illustrated. In 
summary, the following are the steps of the method. 

• A customer notifying it's payment card issuer of an intended transaction prior 
to making the transaction (Fig 1.1). 

• The payment card issuer confirming the notification to the customer. (Fig 
1.2). 

• The customer notifying a purchase request and payment instructions to a 
merchant (Fig 1.3). 

• The merchant system processing the transaction request with an acquiring 
institution (Fig 1.4). 

• The acquiring institution transmitting an authorisation request for the 
transaction to the issuing institution (Fig 1.5 & 1.6). 
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• The issuing institution responding to the authorisation request (Fig 1.7 & 1.8). 

• The acquiring institution relaying the response to the merchant (Fig 1.9). 

• The merchant completing the transaction with the customer (Fig 1.10). 

5 In this method, the cardholder notifies the validation system of the proposed 
transaction. The validation system is at the issuing institution, which issues the 
payment card to the customer. The acquirer bank does not proceed with the 
transaction until a clearance is provided by the issuer's validation system. The 
validation system is able to decline the transaction if the customer does not notify the 
10 issuing institution of the proposed transaction. The validation system is able to 
decline the transaction if it receives different transaction data from the acquiring 
institution in respect of a previously notified transaction. 

The cardholder makes contact with the issuing institution responsible for the 
1 5 payment card. In one instance the cardholder can make this contact using the 
Internet or other home banking system. The issuing institution can validate the 
identity of the cardholder using either a password or a challenge/response 
mechanism. 

20 In more detail, the cardholder informs the issuing institution that a payment 
transaction is going to take place in the future (Fig 1.1). The cardholder supplies 
some specific details and parameters relating to the proposed transaction. This can 
include items such as transaction amount merchant type, merchant name, type of 
transaction, time of transaction and the duration of the validity of this notification. 

25 

The issuing institution confirms the details and parameters of the proposed 
transaction with the customer (Fig 1.2). The issuing institution stores this 
information in the validation system. 



The customer contacts the merchant for the purpose of conducting business. The 
customer supplies his/her payment card details to the merchant for the purchase of 
goods or services. (Fig 1.3) 

The merchant supplies the payment card details with additional transaction 
information (e.g. transaction amount and transaction type) to the acquiring 
institution for verification prior to supplying the goods and services. (Fig 1 .4) 

The acquiring institution sends the transaction information to the issuing institution 
for validation (Fig 1.5). This transaction information may travel through an 
independent payment network (Fig 1.6). The acquirer adds additional relevant 
information to the transaction. 

The issuing institution validates the transaction. This validation process can use the 
details of a previously notified transaction from the cardholder. At the issuing 
institution's discretion, the transaction can be accepted or denied. 

The issuing institution responds to the transaction request (Fig 1.7). This response 
may travel through an independent payment network (Fig 1.8). 

The acquiring institution relays the transaction response to the merchant (Fig 1.9). 

On receipt of an accepted response from the acquiring institution, the merchant and 
the cardholder completes the transaction. 

Referring to Fig. 2, a "CLIP" system performs the issuing bank validation, and the 
following are the signals. 
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1 - The customer informs the issuing bank of a proposed transaction through the 
relevant banking interface e.g. Internet Banking, Telephone Banking, Mobile 
Banking etc. This notification will identify key parameters of the transaction e.g. 
Time, amount, Merchant etc. 

5 

2 - The Customer interface informs the CLEP system within the issuing Bank of the 
proposed transaction detail where it is stored pending a matching transaction arriving 
from the payment network. The issuing bank will set parameters as to how this 
matching occurs. 

#10 

3 - The CLIP system confirms the proposed transaction detail with the issuing 
bank's Banking interface. 

4 - The issuing bank's Banking Interface will notify the customer that it is in receipt 
1 5 of the proposed transaction detail. 

5 - A transaction request is received at the issuing bank's payment authorisation 
system. 

' ) 

20 6 - The issuing bank directs the transaction detail to the CLIP system to validate that 
the details match the transaction details as confirmed by the customer in step 1. The 
issuing bank through pre-set parameters can accept or reject the transaction. 

7 - The CLIP system sends a transaction accept/reject response to the issuing bank's 
25 payment authorisation system. 

8 - The issuer's payment authorisation system relays the response in step 7 to the 
card payment network. 
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An advantageous feature of this invention is that the cardholder notifies the issuing 
institution in advance of using their payment card for a transaction. This allows the 
issuing institution to deny all transactions as a rule, authorising only those 
transactions that it has been notified about in advance by the cardholder. This 

5 ensures that the cardholder has control over the usage of the payment card. This 
control can be finite, down to a particular merchant for a specific amount at a fixed 
date and time. For example, the cardholder can notify his/her bank about a 
transaction at an Internet Bookshop for a particular amount, due to occur in the next 
few hours. The issuing institution will store this notification on the validation system. 

10 When the Internet Bookshop processes the payment card transaction, the issuing 
institution will receive a request for authorisation. The issuing institution can 
compare this transaction request with those notifications stored on the validation 
system. If the notification matches with one stored on the validation system the 
issuing institution can approve the transaction. The issuing institution may perform 

15 other validation tests including checking available funds. The original notification is 
now discarded and cannot be re-used. If there is no match for the transaction request 
on the validation system, the issuing institution can decline the transaction. This 
prevents duplication authorisation requests or unauthorised use of the payment card. 

■•1 



20 



The invention is not limited to the embodiments described but may be varied in 
construction and detail. 
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Claims 

1. A transaction processing method comprising the steps of a customer system 
transmitting a purchase request and payment instructions to a merchant 
system, and the merchant system processing the request with an acquirer 
system and the customer system, characterised in that he method comprises 
the further steps of: 

a customer issuing system being notified of the proposed transaction, and 

the issuing system transmitting an authorisation to allow the proposed 
transaction only if conditions are met. 



2. A method as claimed in claim 1, wherein the customer notifies the issuing 
15 system. 

3. A method as claimed in claims 1 or 2, wherein the acquirer system transmits 
an authorisation request to the issuing system, and relays an authorisation 
response from the issuing system to the merchant system. 

20 

4. A method as claimed in any preceding claim, wherein at least some of the 
authorisation conditions are dynamically transmitted to the issuing system by 
the customer when notifying the issuing system. 

25 5. A method as claimed in any preceding claim, wherein an authorisation 
condition is a transaction value limit. 
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A method as claimed in any preceding claim, wherein an authorisation 
condition is an indication of a particular merchant or group of merchants. 



A method as claimed in any preceding claim, wherein an authorisation 
condition is a time limit for the proposed transaction to take place. 

A transaction processing method substantially as described with reference to 
the drawings. 

An issuing system comprising means for performing issuing system steps in a 
method as claimed in any preceding claim. 

A merchant system comprising means for performing merchant system steps 
in a method as claimed in any of claims 1 to 8. 

A customer system comprising means for performing customer system steps 
in a method as claimed in any of claims 1 to 8. 
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. * Customer Interface includes (but not limited to) 
* Internet Banking 

•Telephone Banking (voice response) 
"Mobile Phone (WAP, m-commerce) 
•Customer Service 
•Home Banking (interactive TV) 
•ATM 
•POS 
.'Branch 



